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Abstract — The NASA Orion Ground Processing Team was 
originally formed by the Kennedy Space Center (KSC) 
Constellation (Cx) Project Office’s Orion Division to define, 
refine and mature pre-launch and post-landing ground 
operations for the Orion human spacecraft. The multi- 
disciplined KSC Orion team consisted of KSC civil servant, 
SAIC, Productivity Apex, Inc. and Boeing-CAPPS engineers, 
project managers and safety engineers, as well as engineers 
from Constellation’s Orion Project and Lockheed Martin 
Orion Prime contractor. 

The team evaluated the Orion design configurations as the 
spacecraft concept matured between Systems Design Review 
(SDR), Systems Requirement Review (SRR) and Preliminary 
Design Review (PDR). The team functionally decomposed pre- 
launch and post-landing steps at three levels of detail, or tiers, 
beginning with functional flow block diagrams (FFBDs). The 
third tier FFBDs were used to build logic networks and 
nominal timelines. Orion ground support equipment (GSE) 
was identified and mapped to each step. This information was 
subsequently used in developing lower level operations steps in 
a Ground Operations Planning Document PDR product. 

Subject matter experts for each spacecraft and GSE subsystem 
were used to define 5 <h - 95 th percentile processing times for 
each FFBD step, using the Delphi Method. Discrete event 
simulations used this information and the logic network to 
provide processing timeline confidence intervals for launch 
rate assessments. 
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The team also used the capabilities of the KSC Visualization 
Lab, the FFBDs and knowledge of the spacecraft, GSE and 
facilities to build visualizations of Orion pre-launch and post- 
landing processing at KSC. Visualizations were a powerful tool 
for communicating planned operations within the KSC 
community (i.e., Ground Systems design team), and externally 
to the Orion Project, Lockheed Martin spacecraft designers 
and other Constellation Program stakeholders during the SRR 
to PDR timeframe. Other operations planning tools included 
Kaizen/Lean events, mockups and human factors analysis. 

The majority of products developed by this team are 
applicable as KSC prepares 21 st Century Ground Systems for 
the Orion Multi-Purpose Crew Vehicle and Space Launch 
System. 
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1.0 Introduction 

This paper provides an overview of the Constellation Ares 
I/Orion/Ground Operations Elements and the Orion ground 
operations flow. The Orion ground operations planning 
process is described including six tools the Ground 
Operations team utilized during the planning process. 
These tools included concept of operations, functional flow 
block diagramming, timelines, modeling, and the use of a 
database to identify and manage tasks and related resources 
such as ground support equipment, safety hazards, 
personnel, and supporting systems. In order to maximize 
operability, Kaizen/Lean events, mockups, human factors 
analysis, and a watch list of operability issues were also 
utilized. The infusion of operability into the Orion flight and 
ground designs using the processes and tools described in 
this paper enabled the Orion flight and ground concepts and 
designs to move forward as NASA transitions to the three 
new Exploration Systems Directorate Programs 
MPCV/Orion, Space Launch System (SLS), and 21 st 
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Century Ground Systems that will launch astronauts to cryogenic propellant servicing, launch countdown, and 
beyond low earth orbit in the coming years. launch are performed. 


NASA Roles and Responsibilities for Ground Operations 


2.0 Constellation Ares I/Orion/Ground 
Ops Elements 

This section provides a general description of KSC Ground 
Operations in support of the Constellation Program, 
including pre-launch preparations, landing, and retrieval. 
Figure 1 illustrates the conceptual flow of the Ares I/Orion 
through the Ground Systems. The Constellation Ground 
System includes the facilities, facility systems, Ground 
Support Equipment, hardware, and software required to 
perform Ground Operations for spacecraft pre-launch 
processing, launch, landing, retrieval, and refurbishing at 
sites in support of the Constellation Program. The official 
configuration for the Ground System is captured in CxP 
72197, Ground Systems Architecture Description Document 
(ADD). The Ground Systems Architecture for the 
Constellation Program is based on a clean pad concept. In 
this concept, the Launch Vehicle (LV) and Spacecraft 
Systems are processed in offline facilities in order to be 
outside of the integrated vehicle critical path and then 
transported to the Vehicle Assembly Building (VAB) for 
integration and test. Some elements and systems, such as 
the launch vehicle upper stage, are delivered to the launch 
site ready for integration and thus taken directly to the VAB. 
In the VAB, the integrated stack is assembled vertically atop 
a mobile platform. Once the vehicle has been completely 
integrated and checked-out on the ML, the ML and Ares 
I/Orion vehicle are moved to the Launch Pad at which final 


a. Providing government oversight and integration of the 
ground processing contracts. 

b. Ensuring that appropriate Ground Operations 
requirements are attained before proceeding to the next 
processing milestone. 

c. Performing project management, baseline management 
and control, data management, budgeting, and scheduling. 
Responsibility also includes ensuring that contractors adhere 
to budgets and schedules. 

d. Planning and executing hands-on operations, as required 
(for example, cargo processing). 

e. Evaluating proposed changes to baselined ground 
operations and providing impacts as required. 

f. Implementation of approved changes to ground operations 
baseline. 

Kennedy Space Center Responsibilities for Ground 
Operations 

a. Orion processing within the Multi-Payload Processing 
Facility (MPPF), VAB, Launch Complex (LC), and landing 
sites. 

b. Launch Abort System (LAS) integration with Orion 
within the VAB 

c. Launch Vehicle processing within the Assembly and 
Refurbishment Facility (ARF); Rotation, Processing and 
Surge Facility (RPSF); VAB; Hangar AF; and Parachute 
Refurbishment Facility (PRF). 




u.s, 



Figure 1 - Ares I/Orion Conceptual Ground Systems Flow 
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See reference [1] Ground Operations Planning Document: 
Volume 3: Operations; Document Number: CxP 72149-03 
for more details on KSC ground operations planning. 


3.0 Orion Ground Operations Flow 

Crew Module (CM)/Service Module (SM) Integrated 
Ground Processing 

CM/SM ground processing includes: 

♦ Acceptance of an integrated CM/SM, transportation to 
the MPPF 

♦ Portable Equipment, Payloads, and Cargo (PEPC) 

Integration 

♦ CEIT (Crew Equipment Interface Test) 

♦ Powered PEPC (Cargo / FCE) to Orion Interface 

Verification Tests 

♦ Un-powered Non-Time Critical PEPC (Cargo / FCE) 
Installation 

♦ High pressure gas servicing ( G02 , GN2, GHe) 

♦ Ammonia servicing (NH3) 

♦ Propellant servicing (N204, MMH , N2H4) 

♦ Closeouts. 

Orion/Launch Vehicle Integrated Stack Processing 

Orion/Launch Vehicle Integrated Stack processing includes 
integration of the Orion to the Launch Vehicle, interface 
testing, integrated testing, and preparation of the integrated 
stack for Launch. Lift and mechanical mate with the upper 
stage Instrumentation Unit (IU) is performed. This includes 
electrical mates, T-0 connections, and purge initiation. The 
the Launch Abort System (LAS) is lifted and mechanically 
mated to the CM. LAS to CM electrical mates are 
performed. LAS Interface Test & S&A rotation test 
(powered) can be performed at this time or after integration 
is complete. Ordnance mates are also completed. Once the 
LAS has been integrated to the CM, the four Ogive panels 
are installed, TPS is closed out, and internal white room 
access is established. After access has been established, full 
vehicle integrated testing is performed with a vehicle power 
up and health status, Interface Verification Test (including 
RF testing) and Countdown Demo Test (CDDT). A potable 
water sample is also taken at this time. 

Pad and Launch Ops 

After rollout from the VAB and connections at the Pad are 
established, Orion communications testing begins. Orion 
power-up and Pad IVT is performed along with 
communication system End-to-End testing. The LAS 
antennas are used at this point. Late stowage, ordnance 
operations, and LAS arm inhibit removals (S&A pins) are 
performed. Just prior to launch, crew ingress is performed 
along with hatch seal leak checks, cabin leak checks, white 
room seal retraction, and Crew Access Arm ( CAA) 
retraction. Final countdown and launch is then performed. 
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Landing and Recovery 

During descent updated landing coordinates are transmitted 
from Mission Control Center (MCC) at the Johnson Space 
Center (JSC) to the pre-staged recovery crew. Auto-safing 
of pyros & fluid systems are performed. A CM beacon 
transmits the location to the recovery crew. The CM is 
removed from the water with the crew on board. Crew 
egress is after the CM is secured on a well-deck ship. The 
pyrotechnics are manually safed and time critical PEPC is 
removed on the ship. Data retrieval may also be performed 
as early as on the ship if required. Data retrieval may also 
be performed at the port or at the deservicing location if not 
time critical. Upon arrival at the port, the CM is transferred 
to the dock and prepared for transportation back to KSC. 
The CM is then transported to the MPPF for deservicing. 

CM Deservicing 

Upon arrival at the MPPF, deservicing preparations are 
made. The CM is cleaned and moved into the MPPF 
deservicing stand. Once in the stand, the seats, and non- 
time critical PEPC are removed. Data retrieval is performed 
and deservicing is initiated. Deservicing includes the 
propulsion system, ammonia system, and high pressure 
gases that were servicing pre-flight. After the deservicing is 
completed, the CM is moved from the deservicing stand, 
configured for transport, and transported along with 
removed components to the O&C. A transfer of the CM 
and components from NASA back to Lockheed Martin 
(LM) is performed at this time and LM dispositions items 
for re-flight or disposal. 


4.0 Orion Operations Planning Process 
and Toolset Overview 

The primary objective of the Orion ground operations 
planning process was to optimize the “operations design” in 
conjunction with the flight and ground systems designs. In 
order to achieve this, high level operational concepts were 
developed during initial Program Formulation using 
conceptual models, deterministic timelines, and historical 
comparisons. 

As the Program matured, task level operational concepts, 
detailed FFBDs, and off nominal events were defined using 
subsystem/task level modeling and design-informed 
probabilistic simulations. Many of these Orion ground 
processing products will carry over to the new 21 st Century 
Ground Systems Program with some modifications to 
accommodate any new requirements. As the Orion Program 
and new 21 st Century Ground Systems Program progress 
forward to Initial Operational Capability (IOC), the more 
detailed operations requirements, procedures, Launch 
Commit Criteria (LCC), and detailed mission schedules will 
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be produced using yet to be developed certified 
requirements verification models and operations 
contractor/govemment partnered manifest assessments. 


4.1 Concept of Operations 

The Concept of Operations formed the basis for ground 
operations planning by describing the Ground System 
architecture in an operational context. It provided a 
common understanding of ground operations and the 
supporting infrastructure to all relevant Government and 
commercial stakeholders. This included characteristics of 
the ground system, interfaces between the ground system 
and other projects, nominal and contingency operational 
scenarios, and system performance expectations. The 
concept of operations is not intended to provide specific 
implementation constraints to Ground System designers, as 
system design and operational requirements are levied only 
through technical requirements documents. Rather, the 
concept of operations is part of the overall architecture 
definition which facilitates the development of technical 
requirements documents by providing: 

a. An operational context for the development of technical 
requirements 

b. A framework within which system design and 
implementation alternatives can be evaluated 

c. Reference data for evaluating the completeness of the 
technical requirements 

d. A mechanism to communicate long term goals and near 
term plans in context to support lower level design trades. 

A sample Concept of Operations spacecraft flow subsection 
is shown in Figure 2. 



Figure 2 - Sample Concept of Operations (Spacecraft) 


4.2 Orion Process Visualization 

The Ground Ops Project team leveraged powerful 
visualization capabilities to plan operations at KSC. The 
team utilized Pro E and Catia models of spacecraft, GSE, 
facilities and personnel from spacecraft flight hardware 
designers and ground systems designers. The visualization 
team imported the models into Delmia to enable operations 
and systems design interaction in a virtual reality 
environment. This capability was used many times to 
influence the design process, and make flight and ground 
systems more operable. The visualizations of the spacecraft 
operations in facilities (i.e., VAB platforms, launch abort 
system assembly, spacecraft servicing in MPPF) were also 
powerful communications tools for engineering 
development and milestone reviews such as GOP PDR. 


4.3 Functional Flow Block Diagrams 

Cx Ground Ops Project required tools to collect, assess, and 
concisely communicate all of the Orion ground operations 
steps including servicing, integration, landing and recovery 
and de-servicing. One simple but effective tool was 
functional decomposition, using Functional Flow Block 
Diagrams (FFBDs), prepared with participation throughout 
the organization at KSC and JSC. Orion Ground Operations 
project led the FFBD effort and maintained the 
configuration control of the product. The first FFBD was 
developed in 2006 and updated on a regular basis depending 
on significant changes to the vehicle or ground systems. 
The use of FFBDs is a standardized practice per NASA 
Systems Engineering Handbook NASA/SP-2007-6105. The 
FFBD will continue to be updated periodically because it 
provides the simplest method of developing and 
communicating Orion operational tasks among different 
project and engineering organizations. It is a time based 
sequencing of the Orion ground operations flow in one 
product and enables functional decomposition of tasks as 
the flight and ground designs evolve and the related 
operations are better understood. The FFBD was also used 
to develop multiple/ lower level GOP products such as the 
nominal timelines, derived requirements, the Orion portion 
of Ground Operations Planning Document (GOPD), and the 
Orion portion of the Ground Operations Timeline Analysis 
Report integrated timeline. The FFBD and timelines were 
also used as input to Orion Ground Ops discrete event 
simulations, visualization tools and to resource planning 
efforts for future O&M. 

FFBD Lessons Learned 

1) Decide on level of detail up front 

2) Decide on ground rules on what’s in and out 

3) Keep the level of detail at the functional level 

4) Keep it simple 

5) Establish some type of configuration control 
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6) Keep a reference version for the community to use (i.e. 
GOPD) and develop working versions for continual 
update and refinement as needed 

7) Get the larger community involved early (Safety, 
Engineering, Operations, Logistics, Institution, etc.) 

8) Use an application that everyone can use. Our team 
used MS Powerpoint. 

9) Expect numerous changes. 

Examples 

Our team began with a very high level Tier 1 FFBD (Figure 
3). As the operations became more understood, Tier 2 and 
Tier 3 levels were developed (Figures 4 and 5). For our 
team, the next level was the GOPD and the actual detailed 
procedures. The Constellation Program (CxP) did not reach 
the detailed procedure level before the program was 
canceled. Many of our FFBD and GOPD details will 
directly apply to the new Exploration Orion ground 
operations FFBD and GOPD. Procedure level details will 
evolve from these in the future. 



Figure 3 - Tier 1 Orion Ground Ops Functional Flow 



Figure 5 - FFBD Tier 3 Example 


4.4 Operations Timeline Development 

Subsystems level ground processing expertise from Shuttle 
and ISS were used to estimate timeline durations and 
resource loading for Orion and the new Program. The 
Delphi method was used to develop durations based on 
multiple experts per subsystem. The timelines were then 
used to develop preliminary schedules. The schedules 
added learning curve, work shifting and special testing. 
Integrated operations at the VAB and Pad, and hazardous 
operations at the MPPF, were based on five days/three shifts 
per week and the remaining offline operations are based on 
five days/two shifts per week. The learning curve was 
based on ISS, Shuttle and Apollo historical data. This data 
set indicated that up to four times the estimated nominal 
steady state may be required to prepare for the first flight, 
and that the timeline duration could be reduced with each 
subsequent flight, until full learning was accomplished after 
the third flight. 
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Figure 4 - FFBD Tier 2 Example 


Ground Operations Timeline Analysis Report (GOTAR) 

The purpose of the GOTAR was to demonstrate the progress 
made by the Ares/Orion/GO Projects towards meeting the 
Program requirements. One requirement was to conduct 
ground operations for a single Ares I/Orion mission within a 
threshold critical path timeline of 879 hours. From 
GOTAR 1 to GOTAR 12 this time was reduced from 920 
hours to 867 hours. Another requirement was to achieve a 
45 calendar day launch interval once the Orion/ Ares I 
system enters steady-state operations. The report provided 
the current assessment status of, and recommended 
improvements for, the overall ground operations 
responsiveness of the Orion/ Ares I system. In order to 
accomplish this, the report officially documented the 
allocation of the 45 calendar day requirement into sequential 
segments. These segments were defined in serial work 
hours as follows: 
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1. Mobile Launcher (ML-1) Refurbishment 

2. Mobile Launcher (ML-1) Preps in VAB High Bay 3 
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3. First Stage Stacking on Mobile Launcher (ML-1) 

4. Upper Stage Stacking 

5. Orion CEV/LAS Installation 

6. Orion/ Ares I Integrated Test and Closeouts 

7. Orion/ Ares I Pad Operations 

The work described above was to be accomplished within 
45 calendar days, inclusive of any contingency time 
accounting for: holidays, weekends, shift differentials, 
accumulation of unplanned work, and other variances. 

The GOTAR report was an integrated source of detailed 
timeline allocations that provided more detailed Level III 
project information to guide the Level III Projects. In 
addition, the report provided timeline assessments against 
the currently known state of the flight and ground system 
designs, as well as quantifying timeline margin (deltas) 
between the assessments and the allocations. The GOTAR 
also provided recommendations for closing the gap between 
the assessment and the allocated requirements. 

Example 


csm 5-daywork 

week 

■HB 6 daywork 
week 

7 daywork 

week 

Total Work 
Days 

— • — Trendline 
Goal 


GOTAR- 10 GOTAR-1 1 GOTAR- 12 

09/0 itS 11/05/09 1/1S710 


Figure 6 - GOTAR Example 

The GOTAR example, shown in Figure 6, shows 7 day 
work week shifting would meet the 45 day requirement and 
that from September 2009 to January 2010 the integrated 
team leaned out 2 Vi days of additional efficiency in the 
integrated timeline. 



at the level of detail required to provide the answer, and to 
complete the DES analysis in time to be useful. The input 
analysis sources were Shuttle historical data, expert opinion, 
CxP documentation, and literature reviews. The Output File 
and output analysis products were designed to match 
requested analysis. DES analysis was performed for ground 
operations needs as follows: 

♦ Maximum flight rate analysis for integrated operations 
at the Vehicle Assembly Building (VAB), Mobile 
Launcher, Pad, and for Orion offline operations at the 
MPPF 

♦ Transporter study 

♦ VAB Highbay selection study 

♦ 90-Minute Launch separation study 

♦ Probability of Meeting Planned Milestones Study 

♦ Launch Probabilities and Launch Distributions for 
Preliminary Design Review (PDR) 

♦ Flypergolic scrubber study. 


4.6 Ground Operations Planning 
Document Database (GOPDb) 


GOPD 

The GOPD (example shown in Figure 7) provides ground 
operations planning information to ground systems 
developers, flight system developers, ground operators and 
the KSC institution. It also provides lower-level operations 
concepts supporting ground system/subsystem development. 
Ground operators are provided with a framework for 
operational procedure development, requirements 
assessment, and workforce/budget planning. Also, the 
institution is informed of the capabilities and services 
required to support ground processing. Details managed 
within the GOPD are information such as tasks, related high 
level work steps, hazardous operations, required 
subsystems, required support services, required GSE, and 
timelines. 

Example 


4.5 Discrete Event Simulation (DES) 
Modeling 


Discrete Event Simulation (DES) is a computer-based 
modeling technique for complex and dynamic systems 
where the state of the system changes at discrete points in 
time and whose inputs may include random variables. The 
related planning products used in our DES efforts included, 
integrated timelines, FFBDs, manifest scenarios, and project 
directed assumptions. The modeling guidelines were to 
model at the level of detail for which there is data, to model 
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GOPDb 
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Figure 7 - GOPD Example. 


The GOPDb is a custom web application that facilitates 
collaborative development of the GOPD. The GOPDb 
provides user-friendly data entry, review, approval and 
reporting of the GOPD task listings, resource listings, and 
nominal timelines. The GOPDb reduces costs and 
development time through real-time data integration, data 
governance, access control, and revision tracking of ground 
operations planning data. The use of the GOPDb eliminated 
the use of a separate application for capturing the concept of 
operations (ConOps) for ground operations planning 
documents and associated timelines. 

GOPDb Enhancements 

Recent GOPDb enhancements allow the smarter use of 
computing resources for data processing by utilizing both 
client-side and server-side resources. This greatly reduced 
the amount of IT hardware needed to host the application 
and provided greater flexibility in deploying the application. 
It now supports 200 concurrent users. Since GOPDb uses 
web-based software, no additional software installations are 
required. The system uses a RIA (Rich Internet 
Application) interface (Figure 8), which removes all 
browser incompatibilities. The GOPDb also provides real- 
time custom reporting with output to a variety of formats 
including Word, PDF, HTML and Microsoft Project XML 
format. The GOPDb allows comparison of two versions of a 
document side-by-side highlighting the difference between 
documents. This “versions” capability allows for “what-if ’ 
operational scenarios to be developed, reviewed, and 



Figure 8 - Example of GOPDb Enhanced Screen Shot with Timeline and Related GOPD Data Fields 
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compared to the baseline operational scenarios. 


5.0 Operability Improvements Using 
Operations Planning Tools 

Operability, in general, can be thought of as the extent to 
which the maximum mission objectives can be achieved at 
the lowest cost over the program lifecycle. Often, improving 
operability means optimizing several competing figures of 
merit. Operability figures of merit specific to Ground 
Operations include the following: 

1) Improvement of safety to personnel and/or 
hardware 

2) Maximization of throughput or flexibility to meet 
dynamic manifest needs, and minimization of 
processing critical path 

3) Minimization of facility/industrial “footprint” 
required to support operations 

4) Maximization of capability to launch on time 

5) Minimization of touch labor. 

Some examples of Orion ground operability successes that 
were achieved, by teamwork between the Cx Orion and 
Ground Operations Projects, are identified in Figure 9: 


destacking will be much faster as an Orion 
integrated vehicle compared to de-integration and 
integration in the critical path with multiple crane 
lifts. 

B) One piece ogive lift capability allows the complex 
integration of the four ogive pieces to be performed 
offline out of the integrated vehicle critical path. 
Contingency de-integration is also much faster 
with less chance for hardware damage 

C) With the elimination of full vehicle power up for 
post flight de-servicing, the operation is much 
quicker and less GSE and personnel are required 
for this task 

D) With the Composite Overwrap Pressurized Vessel 
(COPV) design updated to meet the 100 day 
requirement before depressurization, integrated 
contingency schedules became more realistic. 
Without this capability, contingency operations 
would have become increasingly difficult to 
accomplish. 

Additional significant operability successes were also 
achieved in: E) propulsion systems; F) Pyrotechnics, 
T-0 interfaces, and servicing panels; G) SM Fairing 
removal capabilities; and H) Launch Vehicle to Orion 
interfaces. 


A) The Orion design was changed to add an integrated 
lift capability. With this capability contingency 




A. Orion design changed to 
add Integrated lift 
capability 


G. SM Fairing removal capability 
without de-integration of the CM 

H. Ares/Orion SA/IU Interface 

• Exterior (versus Internal) mating of fasteners 

• Thermal closeout with preformed material 

• Alignment cues for stacking 



B. Design changed to 
a one Piece Ogive 


C. Elimination of full 
Vehicle Power-up for 
Post-Flight Deservlclng 


D. Orion COPVs now meet CARD 100 
day requirement without 
depressurizing 


E. Orion propulsion systems 
optlmlzedfor offline servicing 


Figure 9 - Orion Operability Successes 
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5.1 Kaizen/Lean Events 

Lean/Six Sigma (LSS) principles were used to improve 
operability and affordability in flight and ground systems 
designs. Certified LSS Black Belts led teams in focused 
streamlining and Kaizen events on a number of occasions. 
Such events sought to reduce non-value added activity, 
reduce waste and sources of variability, and improve 
processing efficiencies. 

One example is the Launch Abort System (LAS) assembly 
streamlining event, where LAS processing and hardware 
improvements were offered by preassembling the ogive 
enclosure, reducing re-assembly and reducing fastener 
count. 

Another example is the identification of improvements to 
project-to-project flight hardware delivery schedules. 
Improvements were identified that could reduce production 
to launch timelines, including hazardous commodity 
servicing streamlining, parallel operations, and use of 
pathfinders to reduce initial test flights’ learning curve 
impacts. 


5.2 Mockups 

Mockups are an invaluable tool in any new development 
program. Mockups provide a low cost alternative to pricey 
flight hardware. Mocks also provide the development team 
a quick and easy way to prove or disprove a design or 
operations. Mockups used early in the development cycle 
not only improve the final design, but also help reduce 
costly changes later in the design cycle. 

Examples 

KSC Ground Operations has used mockups extensively in 
the development of both the Orion flight system interfaces 
and the related ground operations systems. KSC used 
mockups of both the KSC “White Room” and JSC Orion 
Crew Module (Figure 10) to help demonstrate the interface 
between the “White Room” and the Ogive fairing. This led 
to a redesign of this interface. 

KSC also was able to demonstrate Crew emergency egress 
from the Crew Module to the “White Room” (Figure 11). 
This was done with the Astronauts in their new prototype 
suits and KSC Fire and Rescue in their new prototype fire 
suits. This demonstration led to many improvements of the 
Orion Crew Module, Astronaut suits. Fire and Rescue suits, 
and “White Room”. 



Figure 10 - “White Room” to Ogive Fairing Interface 



Figure 11 - CM Emergency with Fire Rescue 


Another demonstration was the use of a full scale Orion 
Service Module mockup to help show that Orion could be 
serviced with existing KSC Ground Support equipment 
instead of more expensive new equipment. This gave the 
KSC Operations team confidence that if funding for new 
equipment wasn’t available, they could still support an 
Orion flight. Lastly the full scale SM mockup was also used 
to show if servicing of the SM/CM could be done using 
temporary scaffolding (Figure 12). This proved that 
temporary scaffolding was not adequate from a safety 
standpoint. This was used to help justify better platforms 
for access to Orion. 
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Figure 12 - SM with Scaffolding Access 


5.3 Human factors analysis 

A Human Factors Team was formed consisting of qualified 
human factors engineers, experienced spacecraft operations 
engineers, design engineers, and the design visualization 
team. This visualization team reviewed the flight and 
Ground Support Equipment (GSE) designs for human 
factors. By following the processing timeline, each Orion 
ground operation was analyzed in the KSC Design 
Visualization Lab with human factors and operations 
experts focusing on the hardware to human interactions 
affecting the human performance during assembly, 
maintenance, and inspection of Orion. 

These important meetings with the operations and design 
engineers using the actual flight and ground designs loaded 
into the design visualization tools were a great help during 
the Human Factors Operability Engineering Analysis 
(HFOEA). The team used a modified version of a Human 
Factors Engineering Analysis (HFEA) tool developed by the 
KSC Engineering Directorate by re-arranging the analysis 
spreadsheet to show the timeline of Orion operations. For 
each of the operations, five data fields in the tool were 
populated, including: Human Interfaces, Issue, Processing 
Phase, Risk Analysis, and Recommendations. 

When an issue was discovered in a specific operation, 
applicable human factors standards were identified and 
referenced with the issue. These standards mainly came 
from the Federal Aviation Administration (FAA) Human 
Factors Design Standards (HFDS). For each issue, design 
engineering was brought into the process in order to address 
the issue for human factors design improvements. 
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Example 

The task of moving the Orion short stack pallet into and out 
of the servicing bay was evaluated (Figure 13). Alignment 
of pallet into the servicing bay was considered an issue that 
required further evaluation. An action was taken to assure a 
method is put in place to prevent contact and misalignment 
of pallet with existing bay structure during installation/ 
removal of short stack pallet. A human factors requirement 
was evaluated and applied to the task that states “Users shall 
be protected from making errors to the maximum possible 
extent”. A recommendation was provided to the design 
team to install guide rails on the floor. See reference [2] 
“Human Factors Operability Timeline Analysis to Improve 
the Processing Flow of the Orion Spacecraft” for more 
details on KSC ground operations human factors 
assessments. 



Figure 13 - Orion Short Stack Pallet at servicing bay of 
Multi Payload Processing Facility (MPPF) building. 


Human Factors Lessons Learned 

Early collaboration and planning between the flight and 
ground hardware designers for human factors operability 
engineering analysis (HFEA) is necessary. The program 
level NASA Constellation human factors requirements 
document (HSIR) greatly promoted better human factors 
Systems Engineering and Integration. This improved the 
integration between ground systems and crewed vehicle 
designs for ground processing. Timeline analysis is great 
way to analyze and improve the design of ground and flight 
hardware interfaces for ground processing of the ground 
equipment, and the flight and ground hardware interface. 
Also, the use of qualified human factors engineers on the 
design team was critical. 


5.4 Active Tracking of Flight/Ground 
Issues 

A Microsoft Access database tool was developed in house to 
manage an integrated watch list of issues that affected 
ground operations cost, schedule and performance. Watch 
list database fields included a title, initiator, priority rating 
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of 1 thru 5, impact description, assigned subject matter 
expert, and status. A priority rating of 1 was high-impact to 
Ground Systems for cost, schedule and performance and 
required immediate management attention. A priority rating 
of 5 had minimum impact to GS in cost, schedule and 
performance. The database was set-up to allow the Flight 
Systems, Systems Engineering & Integration and other 
Project Office functions to evaluate the impacts against 
other disciplines. It provided management a quick-look of 
issues that affected or had the potential of affecting the 
Project Office. The database exported output reports to 
Power-point in order to provide easy reporting for multiple 
user needs. 

Example 

Title: Propellant GSE port sizes to prevent cross 
connections (ID 221) 

Initiator: LX-C organization 
Priority Ranking: 3 

Impact Description: Currently the SM fuel & SM 
oxidizer service carts have the same size outlet ports. 
There is a requirement to prevent misconnection of 
commodities. Propellant GSE design needs to account 
for potential cross connection of commodities. This 
can be accomplished with different size outlets. 

Status: 10/8/10 - Design is planning to modify the SM 
Fuel service panel outlets so that they are different from 
SM oxidizer. However, waiting for final GSE-to-Flight 
Interface definition to close. 


6.0. Summary and Forward Plan 

The Ground Operations team was able to bring the Cx Orion 
spacecraft infrastructure to Preliminary Design Review 
readiness level in 2010, using a combination of tools. FFBD 
decomposition, timeline development, discrete event 
simulation modeling, detailed GOPD planning and mockups 
were powerful tools in planning for operations as well as 
developing more operable ground and flight systems. 

In the 2010 - 201 1 timeframe, Constellation was cancelled, 
NASA formed the Exploration Systems Directorate, and the 
Orion Multi-purpose Crew Vehicle (MPCV), Space Launch 
System, and 21 st Century Ground Systems Programs were 
initiated. The Orion MPCV design is very similar to the pre- 
existing design, so NASA plans to leverage existing 
operations, ground and flight systems designs and plans as 
much as possible. Designs will be updated and modified as 
needed for the new launch vehicle and flight rate 
requirements. 

The 21 Century Ground Systems Program will use the 
operations development tools mentioned previously; they 
have proven their effectiveness in preparing for safe, 
operable human exploration missions in the 21 st century. 
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